Let an application authenticate the sign-in it is told about - #101

Reviewer context, kept out of the body. Intent was posted on #82 before any code was written; this implements that shape.

Why the envelope reuses the invitation stack

The invitation attestation issuer already minted RS256 envelopes with kid rotation, issuer/audience, iat/nbf/exp and a random 256-bit jti — four of the six bindings, already specced. Rather than stand up a second signing implementation, the first commit lifts its private issuing path into Attestations/AttestationSigner, and the invitation issuer now delegates to it. One signing implementation is one place to audit.

The two additions are htm/htu for the route and a digest for the body, under RFC 9449 (DPoP) claim names so this is a profile of an existing scheme.

Two deliberate deviations from RFC 9449, both worth a reviewer's attention:

• body_hash is an AuthProxy extension. RFC 9449 has no body digest. It borrows that spec's ath construction but deliberately does not reuse the ath name, which means access-token hash — a DPoP-aware verifier would be actively misled by it.
• htu strips query and fragment, exactly as RFC 9449 requires. NotifyUrl is a fixed configured URL, so scheme + authority + path is the honest binding.

A purpose: sign-in-notification claim prevents an invitation attestation being replayed as a sign-in notification.

Compatibility

Gated on the presence of SignIn:Attestation alone. when_signing_is_not_configured proves the unconfigured path byte-for-byte: it builds a notifier through the released four-argument constructor over the same context and principal and compares — same JSON string, same byte count, non-empty on both sides, and no Authorization header. and_the_body_is_compared_to_the_released_notification runs the same comparison with signing on, proving the envelope is header-only and the body is untouched.

A real defect the implementation pass found and fixed

Convention-based DI resolves the greediest satisfiable constructor. ICanonicalIdentityResolver is not registered by AddSignIns, so adding the signer as a sixth parameter made the container silently fall back to the four-argument constructor — every signed notification would have failed closed in production while every spec stayed green. AddSignIns now constructs the notifier explicitly, as AddInvites already did.

Independently re-verified before merge

I ran the security-critical mutation myself rather than accepting the report. Rewriting the fail-closed branch to fail open — post unsigned when the envelope cannot be issued — fails 4 assertions, and importantly not just the result code: should_not_post_anything_at_all fails in both and_no_signer_was_supplied and and_the_envelope_cannot_be_signed. The negative is paired with the posting fact, so it cannot pass because the notifier is merely broken. Restored byte-identically afterwards, confirmed with diff.

The one assertion that cannot be made to fail — stated, not hidden

The digest is taken over await content.ReadAsByteArrayAsync(), which is the correct construction. But that choice is currently unfalsifiable: mutating it to digest the payload object instead (JsonSerializer.SerializeToUtf8Bytes(content.Value!)) leaves all 394 sign-in specs green, because the anonymous payload is already camelCase and both paths emit identical bytes.

An attempt to close it by pinning that the content had been buffered was reverted — HttpContentHeaders.ContentLength does not reflect LoadIntoBufferAsync, so no observable trace exists. The guarantee is structural: it holds for any future payload whose serializer options diverge, which is exactly when it would start to matter. The strongest falsifiable form is what and_the_envelope_is_verified.should_bind_the_digest_of_the_bytes_that_crossed_the_wire asserts.

Similarly, a hard-coded htm of "POST" is unfalsifiable at the notifier, which only ever posts. The signer unit spec kills it by signing a PUT.

Prerequisite the owner should decide separately

AuthProxy exposes no JWKS endpoint. A verifying application pins public keys by configuration and selects by kid, matching how invitation attestation is consumed today. That works, but it makes key rotation a coordinated config change on both sides rather than a fetch. Worth its own decision.

Deliberately out of scope

The invite-exchange and credential-link back-channels post similar payloads; the invite arm already carries an attestation but binds neither route nor body. Both are now one call on AttestationSigner. The YARP arm and IdentityDetailsResolver's /.cratis/me call are also named in the original request and are not SignInNotifier. Replay memory is the verifier's job — AuthProxy emits a unique jti and does not remember it.

Gates

Debug and Release, both --no-incremental: 0 warnings, 0 errors. AuthProxy.Specs: 1937 passed, 0 failed (baseline 1848). AuthProxy.Security.Specs, touched by the DI change: 228 passed, 0 failed.

Not verified

No real application verified a real envelope end to end — verification is exercised by a spec-side verifier built from the published contract, not by a separate implementation. No key rotation was performed against a live deployment.

Hardening pass — addresses both independent reviews. a0dbe20.

The finding that mattered most

Every constant in the published envelope — htm, htu, body_hash, and the purpose value separating a sign-in notification from an invitation attestation — appeared in exactly one file, and every assertion read that constant and compared it against itself. The whole wire contract was self-referential.

Verified independently before and after. Renaming NotificationPurpose to "invite-stage" previously left all 1937 specs green while every deployed verifier would break and the cross-protocol separation the documentation promises silently collapsed. The same mutation now fails 2 assertions, including should_separate_the_notification_from_invitation_staging. Restored byte-identically, confirmed with diff.

One review claim was refuted, and I checked that myself

The code review reported the duplicate-key guard as only catching a duplicate of the active key, with [A, A, B] + ActiveKeyId = B accepted — and derived a rotation-time crash from it. That premise is wrong. Both validators do GroupBy(_ => _.KeyId, StringComparer.Ordinal).Where(_ => _.Count() > 1) across every key, so that configuration was already rejected. InvitationAttestationConfigurationValidator is therefore unmodified.

What was true is the coverage half: mutating > 1 → > 2 killed nothing, because the only existing spec duplicated the active key and so died to the active-key rule rather than to uniqueness. The guard was live but unpinned, one refactor from silent deletion. Two and_two_signing_keys_share_an_identifier specs now pin it in both validators.

The SingleOrDefault → FirstOrDefault change stands regardless, as belt and braces: if a duplicate ever did reach the signer it threw, and that exception escaped TryIssue and Notify — breaking the sign-in a notifier is documented never to break. It is now pinned by should_not_throw_out_of_the_sign_in on both paths.

Everything else applied

Mutation evidence

22 mutations, each applied, rebuilt and re-run against the full suite — not reasoned. All 32 new assertions confirmed load-bearing, each dying to a single named line. Every negative is paired with a positive baseline dying to the opposite mutation of the same line (e.g. the key-size floor: < 2048 → < 1024 kills the refusal assertions, < 4096 kills the acceptance ones), so no "rejected" assertion can pass because the unit rejects everything.

Still unfalsifiable, unchanged and still disclosed

The body digest over serialized bytes versus the payload object remains unkillable — both emit identical bytes while the payload is camelCase. The guarantee is structural and matters the moment a payload's serializer options diverge.

Gates

Debug and Release, both --no-incremental: 0 warnings, 0 errors. AuthProxy.Specs 1969 passed (1937 before; +32, exactly the new assertions). AuthProxy.Security.Specs 228 passed.

Deliberately not done

Caching SigningCredentials per key — a real cost on the sign-in hot path, but lifted verbatim from the shipped invitation path, so it is a pre-existing concern that deserves its own change rather than riding along here.